[レポート] 高速でPDCAサイクルを回し、ゼロダウンタイムでAWSに移行したPokémon GOプロジェクト #reinvent [GAM304]

こんにちは。DA事業本部の春田です。

本記事は、AWS re:Invent2019の GAM304: Migrating the live Pokémon database to Aurora PostgreSQL のセッションレポートです。

The English version is here.

概要

Learn how the Pokémon Company International stores and supports data for more than 300 million players with the help of AWS. In this session, Jeff Webb (development manager) and David Williams (senior DevOps engineer) discuss how they migrated to Amazon Aurora PostgreSQL and Amazon DynamoDB, resulting in zero downtime for operations. Hear about best practices for migration and get a glimpse into the services supporting Pokémon Go, including AWS Lambda, Amazon Kinesis, Amazon Redshift, and more.

株式会社ポケモンが、AWSを使って3億人を超えるプレイヤーのデータをどのように保管し支えてきたのかが学べます。このセッションでは、開発マネージャーのJeff Webb氏と、シニアDevOpsエンジニアのDavid Williams氏が、ゼロダウンタイムでどのようにデータをAmazon Aurora PostgreSQLとAmazon DynamoDBに移行させたのか議論していきます。マイグレーションのベストプラクティスを知り、AWS LambdaやAmazon Kinesis、Amazon Redshiftなどを使った、Pokémon Goを支えるサービスの中を垣間見ることができます。

スピーカー

• Chris Finch
  • Senior SA Game Tech Evangelist, Amazon Web Services
• David Williams
  • Sr DevOps Engineer, Pokemon
• Jeff Webb
  • Manager, Software Engineering, The Pokémon Company International

Pokémon GOは世界中の人々の生活だけでなく、Pokémon Company International自身のシステムにもに大きな影響を与えました。彼らはサービスの安定稼働させ、ダウンタイムを削減するためにアーキテクチャを再デザインしましたが、そのアジャイルかつデータドリブンな方法は、低コストかつ速い、かなり興味深いものでした。

内容

はじめに

The Pokémon Company International (TPCI)

• 株式会社ポケモンの子会社
• アジア以外のポケモン・サービスを管理
  • 3億2400万のビデオゲーム
  • 約1000本のアニメエピソード
  • 260億枚のトレーディングカード
  • ブランド管理
  • ローカライゼーション
  • マーケティング
  • ライセンス・著作権
  • PokemonCenter.com

Pokémon GOが始まるまで（2016年より前）

Pokemon.comは以下を含む小さなテックチームだった

• Pokemon.com
  • マーケティングとユーザー・エンゲージメント
  • Pokémon TV（過去24年以上に渡るアニメのエピソード）
• Organized Play
  • トレーディングカードゲームのリーグやトーナメントを管理
  • 他のソフトウェアがリーグやトーナメントを管理できるプラットフォーム
  • シーズンを通してチャンピオンシップ・ポイントを収集する
• Pokémon Trainer Club
  • ユーザー登録
  • ユーザーのプロファイル管理
  • 認証
  • 数百万のアカウント
  • Pokémon.comやより小さなデジタル・プロダクトが使用する

Pokémon Traner Club Service (PTCS)

• 目的： ガバナンスや規制のためのユーザー登録とログインシステム
  • COPPA（Children's Online Privacy Protection Act; 児童オンラインプライバシー保護法）
  • GDPR（General Data Protection Regulation; EU一般データ保護規則）
  • 子どもは自分でアカウントを管理できない仕組み
    • オープンチャットへのアクセスを防ぐ
    • 支払い履歴を監視
• サイズ： 数億に到達
• 利用率： 1日数百万のログイン

Pokémon GOの準備

• NoSQLにシフト
  • Key-Valueベースの高速なシークタイム
  • ユーザー数の急増に対してスケールできるアーキテクチャ
• Pokemon.comとOrganized Playへの副作用をゼロに

Pokémon GOローンチ後（2016年7月）

全てが変わったが、サービスやDBパフォーマンスに問題はなかった

• 6ヶ月でPTCSユーザー数成長率が10倍に
• 2017年の終わりには、PTCSユーザー数が2倍に
• 2018年の終わりには、PTCSユーザー数がさらに1.5倍に

サービス安定性の課題（2017年・2018年）

• サービスとDBの可用性に問題
  • ダウンタイム： 6ヶ月で137時間
• ライセンスやインフラのコストが増加
  • 300ノードでサポートが必要に
• エンジニアリングの時間
  • フルタイム・サポート

ビジネス面での動機

• DBの不安定さがユーザー体験に悪影響を与えていた
• Pokémonプラットフォームにモバイル用のサービスを展開し、新たな市場を開拓
• 今後のプロジェクトの成功のためには、以下の目標を達成する必要がある
  1. ダウンタイムやユーザーへの影響を減らすために、サービスやインフラの安定化
  2. DBを管理する運用上のオーバーヘッドを削減
  3. DBに関連するコストを削減

インフラ面での動機

• インデックスが肥大化し、メモリを消費尽くしていた
  • それをサポートするための垂直スケーリング
• オーバースペックなEC2インスタンス
• 複製されるインフラ
  • データとインデックスの複数の余剰なコピーを管理
• 運用上のオーバーヘッド
  • ルーチン処理がもはやルーチンになっていない
  • EC2の再起動やキャパシティ面で予期せぬ挙動
  • DBのバックアップ
  • パッチやアップグレードが管理不可能に

データ層のアーキテクチャ

• 複数のロールをまたがる数百のDBインスタンス
• 全てがEC2 Auto Scalingでデプロイ
• 全てのデータに対して、一つのデータストア

デザイン・ゴール

• マネージドサービスの恩恵
  • 主力ビジネスのためにリソースの使用状況を最適化
• 最適なデータストアを使用
  • イベントデータ
    • 長期分析・調査のためのログインやプロファイル・メンテナンスのレコード
  • ユーザーデータ
    • プロファイル・メンテナンスや認証・認可をサポート
  • 設定やTTLデータ
    • ユーザーの状態や様々なアクティビティを記録する一時データ
• 高可用、安定性、パフォーマンス
  • 転送中と保存時の暗号化
• コスト削減、適切なサイズのインフラ
  • ライセンスコストを除去
  • 必要な分だけ、使った分だけ支払う

Amazon Aurora PostgreSQLを選択

重要な要件 → 子どもたちのデータと一般ユーザーのデータを守る

	メリット	デメリット
Amazon DynamoDB	AWSの主力マルチリージョンサービス 高スケーラビリティ JSONからの以降がより簡単？	暗号化できない（当時） 内部にエキスパートがいない
Amazon MySQL	内部にエキスパート 暗号化 豊富な機能	新しい技術ではない マルチリージョンサービスではない JSONからリレーショナルへETLが必要
Amazon PostgreSQL	内部にエキスパート 暗号化 内製のDB JSONをネイティブでサポート	最新アップデートにラグ マルチリージョンサービスではない

• 2016年夏
  • Pokémon Goがローンチ
  • アーキテクチャをスケールし、適切なサイズに
• 2017年夏
  • 代替できそうなデータストアを調査し始める
  • DynamoDBか、Aurora MySQLか、Aurora PostgreSQL
  • エンジニアチームを登用
• 2018年春
  • DynamoDBはまだ保存時の暗号化をサポートサポートしていなかった
  • Aurora PostgreSQLがネイティブでJSONをサポートしていたため、ベストな選択肢に
• 2018年夏
  • PostgreSQLを認証用のデータベースとして使用
  • 複雑な処理をしたくなかったので、データをJSONへ引き入れ
  • PostgreSQLをMySQLへのランディング・パッドとして、ただ使わない

データ・ドリブンなアプローチ

• 受け入れ基準（Acceptance criteria）
  • 認証： 2k/秒
  • ユーザーサインアップ： 60+/秒
    • 読み込み重視のアプリケーション
  • 管理用の一括クエリ
• テスト
  • ユーザーの発生： 2億
    • ステータスと状況が様々なユーザー
  • パフォーマンス・テストスイート： バースト、ソークテスト
• 改善と反復
  • 管理用一括クエリが機能していなかった
  • スキーマとリレーショナル・フィールドを修正
  • テストを再実行
• 推奨
  • 3億のユーザーを含んだデータベースを移行する場合、推測ではなくデータドリブンなアプローチに基づいて行う

移行計画

• 改善・反復するアプローチ
  • キャッシュの安定性を修正
  • TTLと設定データを移行
  • イベントデータをストリーミングする
• それぞれのフェイズが、独立して価値をもたらすように

移行フェーズ

• 移行前のアーキテクチャ

• 課題： キャッシュノード
  • キャッシュノードの障害によって、アプリケーション全体で15分から1時間以上のデグレーションが発生
• 解決
  • キャッシュノードをElasticacheに移行
  • コードの修正はゼロ
  • 60秒以内へとデクラレーションを最小化

• 全ての設定データやTTLデータをDynamoDBに移行

• 認証とプロファイル管理のレコードをS3に移行 → 統合分析と個々の調査
• これによって、EC2クラスタのサイズ削減に成功

• ユーザーデータをAurora PostgreSQLに移行

Aurora PostgreSQLへの計画

• AWS Professional Servicesにコンタクトを取り、知識のギャップを埋める
  • スキーマの妥当性検証とフィードバック
  • DBのパラメータグループをどうチューニングすべきかアドバイス
  • モニタリングやチューニング計画のためのツール

Aurora PostgreSQLのクラスタデザイン

• PTCインスタンス
  • クラスタエンドポイントへの新しいプロファイルを作成
• 管理インスタンス
  • カスタムエンドポイントを使用
  • Read-onlyのエンドポイントをデフォルトに設定し、全ノード上のread-onlyリクエストを分散
  • すべてのログイントラフィックをカスタムノードへ隔離

• フェイルオーバー
  • 管理インスタンスの一つをフェイルオーバーのエンドポイントに

• サードカスタムエンドポイントを作成
  • 一括クエリを処理
  • 重いトラフィックやプロファイル管理、認証アクティビティを隔離

移行： 抽出・変換・書き出し（Extract-Transform-Load; ETL）

• 変換と書き出し
  • かなり簡単に
  • アクティベートされていないユーザーは消去
  • 最小限のデータ変更かつ、構造的な変更はなし
• 抽出
  • NoSQLクラスタのアーキテクチャを活用
  • 抽出されていないユーザーをMapReduceで検索
  • 抽出過程でバックアップクラスタにいるユーザーをマーク
  • 本番環境でのユーザーの全ての変更をバックアップクラスタに反映

ETL： テスト・修正・反復

• テスト
  • 1100万ユーザーの複数クラスタをセットアップ
  • 数十のテストを実効
  • テストケース、アクティブでないユーザーやユーザーアップデート
• 手順書の2%は書き直していない
• 反復
  • ユーザープロファイルの変更ドキュメント
  • バックアップや抽出を行うサードクラスタを追加

移行当日

• 移行前の全体のアーキテクチャ
• TODO
  • データベースプラットフォーム全体を交換
  • 数千のログインやプロファイル変更、認証リクエストを処理
  • シンプルさとクラスタ間のデータの一貫性を確保

• 一定時間、書き込みアクティビティを無効化
• 最後の抽出処理が終わった後、NoSQLクラスタを停止

• 抽出クラスタを切断

• 全ての認証トラフィックをAurora PostgreSQLへポインティング
• ほとんど誰も気づかないくらいの切断時間だった

• PTCアプリケーションをAurora PostgreSQLクラスタへポインティング
• テスターを導入し、クラスタへ最後の正常性確認

• トラフィックを通し、稼働再開
• 300のEC2インスタンスを終了

どうなったか？

• 良い点（the good）
  • 認証のダウンタイムがゼロ
  • 95%のユーザーで影響なし
  • 期待通りに計画が機能
  • 安定して高いパフォーマンス
• 悪い点（the bad）
  • パッチ
  • 機能しないクエリ
• 最悪な点（The ugly）
  • なし

デザインゴールの振り返り

• マネージドサービスの恩恵を得る
• データごとに適切なデータストアを使用する
• 高可用性、安定性、パフォーマンス
• コスト削減、適切なサイズのインフラ

総評

	旧プラットフォーム	新プラットフォーム	成果
テクノロジー	サードパーティ製のNoSQL	Aurora、DynamoDB、S3	独立したスケーリング、マネージドサービス
インフラ	ノード数300以下	ノード数10〜20以下	年あたり$350〜450万以下の削減
ライセンス	コストがかかっていた	ほぼゼロに	年あたり$350〜450万以下の削減
専門リソース	1.5人のエンジニア	なし	1.5人月の削減
安定性	137時間のダウンタイム（6ヶ月）	0	顧客体験、プライスレス

プロジェクトの回想

• 上手く行ったこと
  • プロジェクトや課題に対して取った、アジャイルアプローチ
  • AWS DB Professional Servicesで、エキスパートの力を借りたこと
  • データの区分しどう処理するか
• 学んだこと
  • データやサービスについての深い理解
  • 以前のアーキテクチャは、思ってた以上にコストがかかっていたこと

テックチームの今後

• 次のフェーズ
  • プラットフォームとサービスを監視、最適化
  • データに対する今後のニーズや変更可能性を理解する
  • 最先端の分析をするための要件を調査
• 新しいアーキテクチャ
  • 共通のデザインパターンやコンポーネントを定義して使用
  • ツールの単純化、マネージドサービスを使っていきたい
  • ドキュメントは必ず残し、整理する
  • データスタンダード、慣例
  • 意思決定にデータを活用する